Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Netkan for issue 2697 #2730

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Netkan for issue 2697 #2730

wants to merge 2 commits into from

Conversation

Dunbaratu
Copy link
Member

This is associated with PR #2729. When PR #2729 is merged, then wait until that merge makes its way into a public release ZIP, and immedaitely after that ZIP is made public, THEN merge this PR into develop and into master.

To see why, see the documentation files that this PR itself edits, which describe this new policy I'll try to adhere to from now on.

@Dunbaratu
Merge this only AFTER the a ZIP release of #2697.
7969136 
Do NOT merge this PR until AFTER branch
"fixes_issue_2697_ClickThroughBlocker" finds its way
all the way into a public release in a ZIP file.

The reason is complex, but it has to do with how
CKAN's bot crawls and reads the kOS.netkan file.
As soon as this edit finds its way into the master
branch, CKAN's bot will see it within a half hour.
If it sees this edit *before* we make a release
from that master branch, it will end up associating
these edits with the previous kOS release, and
falsely adding this new dependency to it.

In general all edits to kOS.netkan MUST wait until
after there's been a release made for those edits.
@Dunbaratu
Moved netkan file edit to its own PR.
2c58c0f
@Dunbaratu Dunbaratu mentioned this pull request Aug 8, 2020
Merged
@Dunbaratu
Copy link
Member Author

NOTE - This is not merged because I had to back-out the merge of #2729 and the clickthroughblocker dependency isn't there yet. Unless the issue I had with it is addressed, I can't make kOS depend on it.

@HebaruSan
Copy link
Contributor

HebaruSan commented Apr 16, 2022 •
edited
Loading

Hi @Dunbaratu, I just stumbled on this while investigating something else and read your kOS.netkan.README_SUPER_IMPORTANT.md documentation (which says kOS.version in a few places where I think you meant kOS.netkan towards the end), and I wanted to suggest a change that might help with maintainability here:

https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN#internal-ckan-files

  1. Create a kOS.ckan file and include it inside the ZIP files for new releases
  2. Move any properties that you consider version-specific from kOS.netkan to kOS.ckan (e.g., conflicts, depends, etc.)

A file with a .ckan extension inside of a release ZIP is treated specially by the bot: it will parse it as CKAN metadata and merge it the fields from whatever .netkan it is processing. After these changes, the NetKAN bot would only see the appropriate metadata for each release, and you could go back to updating metadata in the same pull request as relevant changes are made, as long as kOS.ckan is edited instead of kOS.netkan. Best of all, you could drop the "after the next release" pull requests from your work flow.

I have been using this approach for my own mods for a while now and I like it pretty well. Astrogator now has a very minimal .netkan file and a more verbose .ckan file:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Dunbaratu @HebaruSan