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

Updates to the build recipe for ISIS releases for the 3.7.0 release candidate. #3205

Merged
merged 3 commits into from
Apr 8, 2019
Merged

Updates to the build recipe for ISIS releases for the 3.7.0 release candidate. #3205

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4aeaf58
Minor modifications for RC build
isis3mgr Apr 1, 2019
9665a63
Small modification to version in the recipe/meta.yaml
SgStapleton Apr 2, 2019
86062d3
Updating release stage in isis/version
SgStapleton Apr 2, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions isis/version
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
3.6.1 # Public version number
2019-04-26 # Release date
3.7.0 # Public version number
2019-04-01 # Release date
alpha # release stage (alpha, beta, stable)
1 change: 0 additions & 1 deletion recipe/build.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,4 +2,3 @@ mkdir build
cd build
cmake -GNinja -DJP2KFLAG=ON -Dpybindings=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PREFIX -Disis3Data=/usgs/cpkgs/isis3/data -Disis3TestData=/usgs/cpkgs/isis3/testData ../isis
ninja install
ninja docs
4 changes: 2 additions & 2 deletions recipe/meta.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,12 +12,12 @@
# A Public Release for ISIS3.6.1: {% set version = "3.6.1" %}
# A Release Candidate for ISIS3.6.1: {% set version = "3.6.1_RC" %}
# A custom build of ISIS3.6.1 for the CaSSIS mission: {% set version = "3.6.1_cassis" %}
{% set version = "3.6.1" %}
{% set version = "3.7.0_RC" %}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am just noting what you told me today - while semantic versioning requires hyphenation, we have to use an underscore in the meta.yml. 👍

# This is the branch that conda build will pull from the ISIS repository. If you are building for a
# general public release, leave the branch as "release". If you are building a custom build, like
# for a mission for example, simply change the value to the branch of choice.
{% set git_branch = "release" %}
{% set git_branch = "dev" %}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a branch or should this be a tag?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be doing the build off of a release tarball

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'm confused about the question here...?

Copy link
Contributor

@krlberry krlberry Apr 2, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm even more confused. I can't even find a reference to git_branch in the docs https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#source-section.

But it also looks like git_tag exists, in which case we could use this 3.7.0_RC tag to do the build, which seems correct to me (and is probably what @jlaura was suggesting)? https://stackoverflow.com/questions/22546878/possible-to-do-conda-build-from-github-branch

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SgStapleton @kberryUSGS For the RCs, using the tag makes sense. For the full 3.7.0 release we should be creating a release tarball on github. Then, for the release build we should be using that tarball.

See how we build the csm on conda-forge.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the main concern I have here is when there needs to be a special build for a particular mission. They will need to either pull from a particular branch, or they will need to create a tag for their build in the repository. The latter would probably be preferred to keep track of the snapshots of the repo at particular builds, but I just wanted to make sure this makes sense to everyone.


# This is the build number for the current version you are building. If this is the first build of
# this version, the build number will be 0. It is incremented by 1 with every consecutive build of
Expand Down