Skip to content

Explicitly state PROJECTS_ROOT & PROJECT_SOURCE are reserved#134

Merged
maysunfaisal merged 6 commits intodevfile:masterfrom
maysunfaisal:addReservedEnv
Oct 1, 2020
Merged

Explicitly state PROJECTS_ROOT & PROJECT_SOURCE are reserved#134
maysunfaisal merged 6 commits intodevfile:masterfrom
maysunfaisal:addReservedEnv

Conversation

@maysunfaisal
Copy link
Member

Signed-off-by: Maysun J Faisal maysunaneek@gmail.com

What does this PR do?

This schema explicitly specifies that PROJECTS_ROOT & PROJECT_SOURCE env are reserved and cannot be overridden via component container's env

What issues does this PR fix or reference?

Fixes #132

Is your PR tested? Consider putting some instruction how to test your changes

Docs PR

Copy link
Contributor

@elsony elsony left a comment

Choose a reason for hiding this comment

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

The current approach is to repeat the same info on places that have access to those two variables. Instead of repeating the same info all over the place, will it be cleaner to specify under the container env section and mentioned those two are reserved variable and cannot be overridden? In reality, the user can only override those variables in the container's env setting so it is probably better to put that restriction right on that section.

@GeekArthur
Copy link
Contributor

GeekArthur commented Sep 23, 2020

I have generic comment, is it necessary to add the full definitions for PROJECTS_ROOT and PROJECT_SOURCE to all the places that may potentially use the two env vars? It seems like a little bit redundant and it's not easy to maintain (we have to update all the places if it's necessary). Would it be better to define on one place then let all other places point to that place?

@johnmcollier
Copy link
Member

johnmcollier commented Sep 23, 2020

Yeah, I agree with @elsony, I think we just need a section in the container.env schema that outlines which variables are reserved and can't be set by the user. Much like how we outline allowed env variables in the commandLine definition.

And I like @GeekArthur's suggestion, it would be nice if we could define all of the relevant environment variables in the devfile spec in one spot, rather than having to define them every time we mention them in the spec. Especially if we add more reserved environment variables to the schema in the future, it'll keep the schema cleaner. But TBH, that's outside of the scope of this PR.

@maysunfaisal
Copy link
Member Author

maysunfaisal commented Sep 24, 2020

@elsony @GeekArthur @johnmcollier updated the PR! Makes sense.

EDIT - I moved info regd the env to the env section and just mentioned that these env can be used in the command. Lmk, if it looks cleaner now

@GeekArthur
Copy link
Contributor

@maysunfaisal It looks cleaner to me! I didn't find a PR review guide for this repo, probably we should let the code owner do the final review.

@maysunfaisal
Copy link
Member Author

@davidfestal @amisevsk @sleshchenko Can I pls get a review on this? Thx!

Comment on lines +118 to +120
// - `$PROJECTS_ROOT`: A path where projects sources are mounted
// - `$PROJECTS_ROOT`
//
// - `$PROJECT_SOURCE`: A path to a project source ($PROJECTS_ROOT/<project-name>). If there are multiple projects, this will point to the directory of the first one.
// - `$PROJECT_SOURCE`
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure about removing the descriptions of the variables here is a good idea (at least, without some other, centralized location we can link to to explain it). Currently, the only way to figure out what $PROJECTS_ROOT and $PROJECT_SOURCE are to be used for is by checking the description for env, where the main purpose is to tell you that you can't override them. Basically, my thinking works out to:

  • ExecCommand (the use-site): Describe what the variables can be used for
  • Container (the define-site): Describe which variables can be overridden (or not)

An alternative if we want to keep the command descriptions terse is to e.g. link to a docs page (once a description of reserved env vars is added -- e.g. here).

Alternatively, a more generic doc would remove the "Special variables..." entirely; isn't it the case that you can use any environment variable in a command? The only difference for $PROJECTS_ROOT and $PROJECT_SOURCE is that they're supposed to automatically be set, but you should be able to reference e.g. $M2_HOME, etc. here as well.

// The actual command-line-string. Note environment variables from the container the command runs 
// in can be used in the command, e.g. 
//
// `cd ${PROJECT_SOURCE} && mvn clean install` 

I'm less certain this applies to the workingDir, where I think documenting the automatically-defined env vars is useful.

Copy link
Member Author

Choose a reason for hiding this comment

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

That makes sense. I've reverted the changes and just kept the section about reservation in env.

I've opened #138 to discuss and track on how we can define special variables in devfile spec context, as that seems to be out of this PR's scope.

@sleshchenko sleshchenko requested a review from elsony September 28, 2020 06:39
Signed-off-by: Maysun J Faisal <maysunaneek@gmail.com>
Signed-off-by: Maysun J Faisal <maysunaneek@gmail.com>
Signed-off-by: Maysun J Faisal <maysunaneek@gmail.com>
Signed-off-by: Maysun J Faisal <maysunaneek@gmail.com>
Signed-off-by: Maysun J Faisal <maysunaneek@gmail.com>
@maysunfaisal
Copy link
Member Author

I've rebased and updated the PR!

\n - `$PROJECT_SOURCE`: A path to a project source
($PROJECTS_ROOT/<project-name>). If there are multiple
projects, this will point to the directory of the first
one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period

A path to a project source ($PROJECTS_ROOT/<project-name>).
If there are multiple projects, this will point to the
directory of the first one."
directory of the first one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period

Copy link
Member Author

Choose a reason for hiding this comment

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

The reason I removed the ending period is because I thought a bullet point should not necessarily have an ending period and the schema was inconsistent in this way. Some had and some didnt. So I removed the periods from the struct i was working on

Copy link
Member Author

Choose a reason for hiding this comment

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

I've checked online and the general rule is; complete sentences should have periods and fragmented sentences should not have periods. I've updated the PR accordingly.

A path to a project source ($PROJECTS_ROOT/<project-name>).
If there are multiple projects, this will
point to the directory of the first one."
point to the directory of the first one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period

\ - `$PROJECT_SOURCE`: A path to a project
source ($PROJECTS_ROOT/<project-name>). If
there are multiple projects, this will point
to the directory of the first one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period

A path to a project source ($PROJECTS_ROOT/<project-name>).
If there are multiple projects, this will point
to the directory of the first one."
to the directory of the first one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period

a project source ($PROJECTS_ROOT/<project-name>).
If there are multiple projects, this will point
to the directory of the first one."
to the directory of the first one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period

source ($PROJECTS_ROOT/<project-name>).
If there are multiple projects, this will
point to the directory of the first one."
point to the directory of the first one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period

sourceMapping \n - `$PROJECT_SOURCE`: A path to a project
source ($PROJECTS_ROOT/<project-name>). If there are multiple
projects, this will point to the directory of the first
one"
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing ending period. The same for the rest so just do a search and I am not marking the others.

Signed-off-by: Maysun J Faisal <maysunaneek@gmail.com>
Copy link
Contributor

@elsony elsony left a comment

Choose a reason for hiding this comment

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

LGTM

@maysunfaisal maysunfaisal merged commit f6de71b into devfile:master Oct 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Should PROJECTS_ROOT and PROJECT_SOURCE be reserved environment variables?

8 participants